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SECTION  I 


INTRODUCTION 


This  report  is  Volume  3 of  a three-volume  report  on  the  design  of 
a security  kernel  for  Multics.  This  volume  presents  the  top-level 
specification  of  some  of  the  secondary  subsystems  of  some  of  the 
llultics  kernel.  The  design  methodology  is  discussed  in  Volume  1 of 
this  report,  and  the  details  of  the  specification  language  used  are 
given  in  Volume  2. 

Three  secondary  subsystems  of  the  Multics  kernel  are  discussed  in 
this  volume.  The  functions  presented  in  this  paper  are  different  from 
those  presented  in  Volume  2 because  they  are  not  intended  for  use  by 
normal  Multics  users. 

The  first  subsection  discussed  is  the  System  Security  Officer 
(SSO).  The  SSO  is  the  direct  interface  between  the  kernel  and  a user 
responsible  for  system  security.  The  SSO  interface  is  important 
because  it  provides  some  functions  that  cannot  be  performed  by  normal 
users  because  they  do  not  follow  all  the  security  rules. 

Next,  hardware  reconfiguration  is  discussed.  The  reconfiguration 
functions  provided  are  to  be  used  only  by  system  high  processes  and 
allow  the  user  to  dynamically  alter  the  hardware  configuration  of  the 
system.  It  is  intended  that  the  supervisor  running  on  the  kernel 
restrict  the  use  of  these  functions  to  the  operator. 

Finally,  the  initialization  of  the  Multics  kernel  is  discussed. 
Initialization  provides  the  kernel  with  an  initial  secure  state  that 
will  be  maintained  as  secure  by  the  kernel  0-functions. 

Other  security-related  subsystems,  such  as  the  Salvager  and  the 
Emergency  Shutdown  subsystems,  are  not  discussed  in  this  volume. 
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SECTION  II 


THE  SYSTEM  SECURITY  OFFICER  (SSO)  INTERFACE 


TRUSTED  SUBJECTS 

A secure  computer  system  is  not  a closed  system.  External  inputs 
are  required  to  complete  and  maintain  security.  A mechanism  is 
required  to  associate  the  computer  system  elements  correctly  with 
their  counterparts  in  the  people/paper  world.  Unverified  software 
cannot  be  trusted  to  make  these  bindings. 

All  software  on  which  the  security  of  the  computer  system  depends 
must  be  verified  to  perform  its  required  function  correctly  if  the 
system  is  to  be  certified.  The  kernel  software,  the  software  that 
implements  the  reference  monitor,  represents  part  of  the  verified 
software  of  the  system.  The  remainder  of  the  verified  software 
comprises  the  "trusted  subjects":  the  active  system  entities  that 
perform  the  security-related  binding  of  computer  system  elements  to 
the  external  environment. 

There  are  two  areas  in  the  Multics  system  where  trusted  subjects 
are  needed.  One  area  is  initialization,  v/hich  is  treated  in  the  last 
section.  The  other  area  is  the  interface  between  the  kernel  and  the 
System  Security  Officer  (SSO).  This  section  describes  the  nature  of 
trusted  subjects  and  the  SSO  Interface  specification. 

The  verification  technique  requires  that  all  software  to  be 
certified  have  a top-level  specification.  Because  of  the  distinctly 
different  duties  of  trusted  subjects,  however,  the  requirements  of 
their  interface  specification  are  unlike  those  of  the  kernel. 

The  arguments  (external  information)  required  by  trusted  subjects 
are  supplied  by  users  who  are  trusted  to  perform  correctly,  or  by 
hardware.  An  example  of  a hardware-supplied  argument  is  a unique 
identifier  of  a terminal,  supplied  by  the  hardware  of  the  terminal  or 
its  controller.  The  trusted  subject  functions  must  be  performed 
completely  by  verified  software,  since  security  depends  on  their 
correct  operation.  The  trusted  subject  functions  must  interact 
directly  with  the  trusted  users. 

Since  the  users  of  trusted  functions  are  themselves  trusted,  the 
access  control  performed  at  the  kernel  interface  is  not  required  at 
the  trusted  subject  interface.  Nevertheless,  the  requirement  of 
direct  interaction  with  users  implies  that  an  additional  mechanism 
must  be  supplied  to  ensure  trusted  subject  functions  are  only 
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available  to  trusted  users.  Since  this  mechanism  is  implementation 
dependent,  a narrative  description  is  provided,  rather  than  a 
high-level  specification. 


THE  SSO  INTERFACE  DESIGN 

The  most  significant  part  of  the  design  of  the  SSO  interface,  how 
to  ensure  direct  interaction  with  trusted  software,  cannot  be  speci- 
fied. The  enforcement  of  availability  of  the  functions  is  an  imple- 
mentation dependent  mechanism.  One  possible  implementation  is  to 
provide  the  SSO  functions  in  a verified  process  invoked  by  the 
power-on  interrupt  of  a terminal.  A verified  process  is  required 
since  it  must  handle  terminal  communications  completely.  No  uncerti- 
fied software  may  be  interposed  between  the  SSO  function  and  the  SSO 
— even  for  menial  tasks  like  I/O  — as  it  would  then  be  possible  to 
spoof  the  SSO  or  the  SSO  function  and  cause  a breach  of  security. 

The  process  providing  the  interface  functions  must  be  protected 
such  that  software  may  not  invoke  it.  By  implementing  the  process  as 
an  interrupt  service  routine  for  the  terminal  power-on  interrupt,  it 
can  be  ensured  that  only  terminals  and  no  software  may  execute  the 
process.  Of  course,  only  certain  kinds  of  terminals,  with  the  proper 
hardv/are,  may  be  used. 

The  SSO  completes  the  computer  security  mechanism  by  providing 
necessary  external  inputs  and  performing  operations  that  cannot  be 
performed  within  the  constraints  of  the  kernel  interface. 

The  functions  required  by  the  SSO  that  have  been  identified  are: 
a function  to  inform  the  kernel  of  current  device  access  levels,  a 
function  to  remove  quota  from  an  upgraded  directory,  a function  to 
downgrade  segments,  and  functions  to  allow  the  SSO  to  process  logical 
volume  mount  requests.  The  first  function  provides  external  informa- 
tion to  the  kernel.  The  last  two  functions  provide  kernel  information 
to  the  outside  environment,  and  external  information  to  the  kernel,  as 
explained  below.  The  others  perform  needed  functions  that  cannot  be 
performed  under  the  restrictions  of  the  kernel  interface.  The 
requirements  for  verification  of  the  functions  and  relaxation  of  secu- 
rity controls  imply  that  the  functions  must  be  performed  by  trusted 
subjects. 

The  SSO  must  be  able  to  inform  the  kernel  of  device  access  levels 
because  the  kernel  has  no  way  to  ascertain  this  information  by  itself. 
For  example,  when  SECRET  paper  is  mounted  in  a printer,  the  kernel 
must  be  informed  of  the  access  level  of  the  printer.  The  levels  of 
disk  and  tape  drives  must  also  be  made  known  to  the  kernel. 
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Moving  quota  from  an  upgraded  directory  back  to  its  parent  is 
reading  information  from  a higher  level  (the  upgraded  directory)  and 
writing  it  at  a lower  level  (of  the  parent).  Therefore,  this  function 
violates  the  ^-property  and  is  not  allowed  at  the  kernel  interface. 

The  SSO  must  perform  this  function,  since  the  SSO  is  permitted  to 
violate  the  ^-property  in  a controlled  manner. 

Downgrading  segments  is  another  function  that  violates  some  prop- 
erties of  the  security  model  and  hence  cannot  be  performed  at  the 
kernel  interface.  The  SSO  has  a function  to  set  the  access  level  of 
segments.  This  function  is  used  to  downgrade  segments. 

When  a process  calls  the  “Mount**  function  to  mount  a logical 
volume,  and  that  logical  volume  is  not  already  mounted,  **Mount**  enters 
a request  to  the  SSO  to  mount  the  volume.  The  list  of  requests  is  a 
first-in-first-out  stack,  so  the  SSO  has  a function  to  read  the 
earliest  mount  request.  After  he  has  read  the  request,  the  SSO  mounts 
the  appropriate  volume (s),  and  then  uses  other  SSO  functions  to  inform 
the  kernel  that  the  logical  volume  is  mounted  for  the  requesting 
process,  and  which  drive (s)  it  is  mounted  on. 

As  with  the  kernel,  a trusted  subject  has  no  way  of  guaranteeing 
the  identity  of  a user,  so  it  must  rely  on  its  ability  to  identify 
terminals  and  on  physical  security  to  ensure  that  only  the  SSO 
executes  the  functions  provided  by  the  SSO  trusted  subjects. 


COMPATIBILITY  WITH  THE  CURRENT  t-IULTICS 

Most  of  the  SSO  functions  have  no  analogue  in  the  current  Multics 
since  the  security  policy  they  are  concerned  with  is  not  a part  of  the 
current  Multics.  Compatibility  is  not  a problem  because  all  of  the 
SSO  functions  will  have  a restricted  number  of  users. 


SPECIFICATION 

\/hereas  the  security  kernel  is  concerned  with  the  process  as  the 
specification  representation  of  a subject,  in  the  specification  of  the 
trusted  software,  the  terminal  embodies  the  active  subject.  The 
terminal  acts  as  proxy  for  the  user,  since  we  lack  the  hardware  capa- 
bility to  identify  different  users  on  a terminal. 

Corresponding  to  the  process  control  function  **process**,  which 
embodies  all  process  information,  the  trusted  subject  module  uses  a 
hardware-supplied  argument  **terminal**  to  determine  if  the  user  of  the 
function  is  using  the  SSO  terminal.  This  hardware-supplied  argument 
appears  in  angle  brackets  (<>)  in  function  argument  lists. 
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The  sections  that  follow  provide  descriptions  of  the  SSO  specifi- 
cation itself,  broken  down  by  parts  of  the  specification, 

SSO  Types,  Parameters,  Constants,  and  Definitions 

Figure  1 illustrates  the  SSO  type  definitions,  parameters, 
constants,  and  definitions.  There  are  three  data  types  defined  in  the 
specification.  The  first  two  are  related  to  user-specified  segment 
pathnames,  and  the  last  is  concerned  with  requests  to  mount  logical 
volumes. 

The  SSO  is  the  only  part  of  the  kernel  specification  that  identi- 
fies segments  by  their  pathname.  The  SSO  interface  is  an  interface  to 
a person,  not  a program,  so  it  is  more  convenient  and  less  error-prone 
to  identify  segments  by  their  pathname  rather  than  their  segment 
number.  The  abstract  form  of  a Ilultics  pathname  is  defined  by 
’*path_jiame_type**.  According  to  this  definition,  a pathname  is  a 
vector  of  entrynames.  Thus,  **path__name_type**  is  the  abstract  data 
type  of  a pathname  as  entered  by  a user. 

Each  entryname  in  a pathname  (except  the  last  one)  is  the  name  of 
a directory  (the  parent  directory)  that  contains  information  that 
describes  the  next  entryname.  When  entered  by  a user,  a Ilultics  path- 
name begins  with  a **>**,  which  is  shorthand  for  **root>**.  In  our  secure 
Ilultics  system,  the  root  has  a defining  entry  which  is  stored  in  the 
root  directory.  Therefore,  the  parent  directory  of  the  root  is  the 
root  itself.  Therefore,  if  we  wish  to  precisely  specify  a Multics 
pathname,  we  must  start  the  pathname  with  "rootroot>".  We  need  to 
represent  a pathname  v;ith  this  precision  in  the  specification,  so  we 
have  another  data  type  that  describes  this  "full"  pathname.  This  data 
type  is  called  "f ull_j)ath_name_type".  In  the  rest  of  this  document  we 
will  refer  to  this  latter  type  of  pathname  as  a "full"  pathname,  and 
to  the  pathname  the  user  enters  as  a "regular"  pathname. 

The  last  type  definition  is  of  a mount  request,  which  specifies 
that  the  given  process  wants  the  given  volume  to  be  mounted. 

The  parameter  "path_name"  is  the  regular  pathname  of  a segment. 
Similarly,  "full_path"  is  the  full  pathname  of  a segment.  The  param- 
eter "terminal",  as  mentioned  before,  is  the  hardware-supplied  uid  of 
the  terminal  calling  the  SSO  function.  The  constant  "max_path_length" 
is  the  maximum  number  of  entrynames  allowed  in  a regular  pathname,  and 
the  constant  "SSO"  is  the  uid  of  the  SSO  terminal. 

In  the  definition  section,  "path__name_length"  is  the  number  of 
entries  in  a regular  (user-supplied)  pathname,  "f ull_jpath__name"  is  a 
full  pathname  (as  created  by  the  "Make_f ull_path_name"  V-function 
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/*  SSO  type  definitions  */ 
type 

path_name_type  = vector (1  to  max_jpath_length)  of  entry__type 
f ull_path_name_type  » vector (1  to  inax_path_length+2)  of  entry_type 
mounter equest_type  « structure 
(process : uid__type, 
vol_id:  uid_type) 


/*  SSO  parameters  */ 
parameter 

path_name:  path_name_type 
full_path:  full_path_jiame_type 
terminal:  uid_type 


/*  SSO  constants  */ 
constant 

max_path_length:  integer 
SSO:  uid_type 


/*  SSO  definitions  */ 
define 

path_name_length  = cardinality{i  | path_jiame[i]  ^ ”undef ined**}; 
full_path_name  = Make_full_path_narae(path_name) ; 
f ull_j)ath_jiame_length  =*  cardinality 

{i  I fulljath_name [i]  ^ “undefined**}; 
full__path_length  =*  cardinality 
{i  I full_path[i]  ^ **undef ined**>; 

Branch_path  = Directory 

(Path_to_uid(Parent_path(full_path_name) ) , 
f ull_path__name  [f  ull_jpath_jiame__length] ) ; 

Dir_branch_j)ath  = Directory 

(Path_to_uid(Parent_j)ath(Parent_path(full__path_name) ) ) , 
f ull_path_jiame  [full_path_name__length-l] ) ; 


Figure  1.  SSO  Types,  Parameters,  Constants,  and  Definitions 
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macro),  and  ”f ull_path_name_length"  is  the  number  of  entries  in  a full 
pathname.  The  definitions  "full_path_name”  and 

"f ull_path_jiame_length"  are  used  only  by  0-functions  and  in  defini- 
tions used  by  0-functions. 

The  number  of  entries  in  a "full_path"  is  given  by 
"f ull__path_length".  Remember  that  ”full_path”  is  a parameter  to  a 
V-function,  so  "f ull_path_length"  is  used  only  by  some  V-functions 
(those  which  are  passed  full  pathnames). 

The  last  two  definitions  are  used  only  by  0-functions  or 
V-functions  with  regular  pathnames  as  arguments.  "Branch__path**  is  the 
directory  branch  associated  with  a **path_jiame”.  "Dirjbranchjbath”  is 
the  directory  branch  associated  with  the  parent  (directory)  of  a 
"path_name**. 

SSO  V-function  Macros 


The  SSO  V-function  macros  are  given  in  Figure  2.  All  of  these 
V-function  macros  are  associated  with  pathnames. 

"Make_full__path_name**  takes  as  its  argument  a regular  pathname 
and  returns  a full  pathname.  A full  pathname  is  a regular  pathname 
v/ith  **root>root**  concatenated  at  the  beginning.  This  macro  is  used 
only  in  the  definition  of  "f ull_path_jiame”. 

The  remaining  three  macros  take  full  pathnames  as  arguments. 
”Parent_path"  returns  the  full  pathname  of  the  parent  of  the  specified 
full  pathname.  ”Path_accessible"  is  a boolean-valued  function  that 
tells  whether  the  specified  full  pathname  exists  and  can  be  accessed 
by  the  SSO  at  its  current  access  level.  "Path_to_uid"  converts  the 
given  full  pathname  to  the  uid  of  the  segment. 

SSO  V-functions 


Figure  3 illustrates  the  SSO  V-functions,  both  hidden  and  non- 
hidden. 

The  hidden  V-function  **Mount__request"  is  the  list  of  mount 
requests  compiled  by  the  "Mount”  0-function  and  processed  by  the  SSO 
with  the  ”Read_jnount_request”  OV-function. 

The  non-hidden  V-function  "SSO_access_level”  represents  the 
current  access  level  of  the  SSO  and  is  derived  from  the  access  level 
associated  with  the  SSO  terminal.  The  exception  for  this  function 
assures  that  the  user  is  at  the  SSO  terminal. 
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/*  SSO  V__function_macros  */ 


y_f  unction_macro  Make_full__path_name(path_jiarae) : f ull_path_jiame_type 
derivation 

Make_full_path_naine  [1]  = "root"; 

Make_f  ull_path_jiame  [2)  = "root"; 

(ViG{l,2,  •••  path_jiaine_length}) 

(Make_f  ull_path_name  [i+2]  * path_narae  [i] ) ; 

(V  i _>  path_naine_length+2)  (Make_full_path_jiame  [i]  =»  "undefined"); 

V_f  unction_jaacro  Parent_path(full_path) : f ull_path_naTne_type 

derivation 

if  full_j)ath__length  = 0 

then  Parent_path  = "undefined"; 

else  (V  i G {1,  2,  ...  , full_j)ath_length-l }) 

(Parent_path [i]  = f ull_path [i] ) ; 

(V  i full_path_length)  (Parent_path  [i]  * "undefined"); 

end 

y_f  unction_macro  Path_accessible(f  ull__path) : boolean 
derivation 

if  f ull_j)ath_length  * 0 

then  Path__accessible  = true; 
else  Path_accessible  = 

if  Path_accessible(Parent_path(f  ull__path) ) 
then  Entry_jdef ined(Path_to_uid(Parent_path(full_j)ath) ) , 
f ulljath  [full_j)ath_length] ) & 

Dominates (Device (SSO) .access_level. 

Directory  (Path_to_uid(Parent_path(full_path) ) , 
full__path  [f ull_path_length] ) .access^level) ; 

end 

end 

y_f  unction^macro  Path_to_juid  (f  ull_j>ath) : uid_type 
derivation 

if  f ull_path__length  = 0 

then  Path_to__uid  « root_uid; 

else  Path_to_uid  * Directory  (Path_to_uid(Parent_path(full__path) ) , 
f ull_path  [f  ull__path_length] ) .uid; 

end 


Figure  2.  SSO  V-function  Macros 


12 


/*  SSO  Hidden_V_function  */ 

Hidden_V_f unction  IIount_request (tine) : mount_request_type 


/*  SSO  V-function  */ 


V_function  SSO_access_level(<terininal>) ; acces8_level_type 

exception 

^terninal  = SSO; 

derivation 

Device (SSO ) . acces8_level ; 


Figure  3.  SSO  V-functions 
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SSO  OV-functlon 


The  SSO  has  one  OV-f unction,  **Read_mount_request,**  as  shown  in 
Figure  4.  This  function  has  as  its  value  the  earliest  mount  request, 
and  deletes  that  request  from  the  list  once  it  has  been  returned.  The 
exceptions  check  that  the  caller  is  at  the  SSO  terminal,  that  the  SSO 
is  executing  at  **system_high, **  and  that  there  is  a mount  request  to 
return. 

SSO  0-functions 


The  SSO  0-functions  appear  in  Figure  5.  These  0-functions  manip- 
ulate kernel  information  but  are  trusted  to  do  so  securely;  excep- 
tions check  the  consistency  of  the  arguments. 

**Set_segment_al**  is  an  SSO  function  used  to  declassify  informa- 
tion by  changing  the  level  of  the  segment  that  holds  it.  Although  in 
the  people/paper  world  individuals  are  allowed  to  do  a form  of  declas- 
sifying by  extracting  paragraphs  from  documents,  the  analogous  mecha- 
nism cannot  be  supported  here  due  to  the  granularity  of  the  informa- 
tion protection  unit. 

The  exceptions  insure:  that  the  caller  is  at  the  SSO  terminal; 
that  the  segment  specified  is  accessible  by  the  SSO  at  its  current 
access  level;  that  the  segment  specified  is  not  the  root;  that  the 
new  access  level  remains  increasing  as  you  move  down  the  hierai^chy; 
that  the  segment  is  not  a non-empty  directory;  and  that  segment  does 
have  terminal  quota. 

The  effect  is  simply  to  change  the  access  level  of  the  segment, 
and  to  revoke  any  current  access  each  process  has  to  the  segment. 

**Set_jievice_jal**  is  used  by  the  SSO  to  inform  the  kernel  of 
changes  in  device  usage.  An  example  is  changing  of  paper  in  a printer 
to  allow  it  to  print  information  at  a different  security  level;  the 
kernel  must  be  given  this  external  information  by  the  SSO. 

The  exceptions  check  that  the  function  is  being  invoked  by  the 
SSO  terminal,  that  the  new  access  level  is  within  the  bounds  allowed 
for  the  device,  and  that  no  process  is  using  the  device. 

This  function  can  also  be  used  to  change  the  level  of  the  SSO 
terminal,  since  this  terminal  is  considered  a device  in  the  specifica- 
tion. The  SSO  terminal  has  a device_id  of  **SSO**,  so  **Device(SSO) **  is 
the  SSO  terminal. 

The  **Remove_upgraded_quota**  function  is  used  by  the  SSO  to  remove 
quota  from  an  upgraded  segment  and  return  it  to  its  parent.  This 
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/*  SSO  OV-function  */ 


OV__f  unction  Read_mount_request  (<terminal>) : mounter equest__type 

exception 

^terminal  * SSO; 

Device (SSO ) .access_level  ^ "systenMiigh”; 

Mount__request  * ’*undef ined”; 

effect 

Mount__request (min{ (itime) ("Mount^request (itime)^="undef ined”) }) 
"undefined**; 

derivation 

'Mount_request  (i!iin{  (itime)  ( 'Mount_request  (itime) '^“"undefined**)  )) 


Figure  4.  SSO  OV-f unction 
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/*  SSO  0-functions  */ 


0__f unction  Set_segment_al(path_name,  access_level,  <terminal>) 

exception 

^terminal  « SSO; 

^Path_accessible(f  ull_j)ath_jiame) ; 

Path_to__uid(full_j)ath_name)  = root__uid; 

^Dominates (access_level,  Dir_branch_path.access_level) ; 

Branch_j>ath.  type  = "directory"  & 

(tientry) (Entry_def ined(Branch_j)ath.uid,ientry) ; 

Branch  path. quota  given  ^ 0; 

effect 

Branch_j)ath.access_level  = access_level; 

(Viprocess_id,  iseg) 

if  ''Process (iprocess_id) . KST (iseg) . uid  = Path_to_uid(f ull_j>ath_name) 
then  Process (iprocess_id). KST (iseg)  = "undefined"; 
end 


0__f unction  Set__device__al(device__id,  access_level,  <terminal>) 

exception 

^terminal  = SSO; 

^Dominates  (Device (device__id)  .max_al,  access_level)  ; 

‘"'Dominates  (access_level.  Device (device__id)  .min_al) ; 

^Dominates (Device (SSO ) .access^level,  Device (device_id) .access__level) ; 
Device (device__id)  .owner  ^ "undefined"; 

effect 

Device (device_id ) • access_level«access_level ; 


Figure  5.  SSO  0-functions 
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0_f unction  Reinove_jipgraded_jiuota (path_name,  quota,  <terininal>) 

exception 

"*teriainal  = SSO; 

"^Path^accessibleCfull^path^name) ; 

Path_to_uid(full_j)ath_jiaiae)  = root_uid; 

^quota  > 0; 

(Branchjath. type  "directory")  & 

(Dir_J)ranch_path.sons_yol_id  ^ Branch_j)ath.sons_vol_id) ; 
Branch_path. quota  = 0; 

Branch_path. quota  - quota  < Branch_path. quota_used; 

Branch  path« quota  given  - quota  ^ 0; 

effect 

Branch  path« quota  given  « 'Branch_path. quota_given  - quota; 
Branch__path. quota  = 'Branch_path. quota  - quota; 
Dir_j3ranch_path. quota  « 'Dir_Jbranch_path* quota  + quota; 


O_function  Set_J)rive(drive_jio,  vol_id,  <terminal>) 

exception 

'"terminal  = SSO; 

Device  (SSO ) .access_level  ^ "system_Jiigh"; 

(f  iprocess) (Process (iprocess) .mount_list (Drive (dr ive_jio ) ) ) ; 
effect 

Drive (drive_no)  = vol_id; 


0_f unction  Set_jnount_list (process_id,  vol__id,  <terminal>) 

exception 

'"terminal  ® SSO; 

Device (SSO ).access_level  ^ "system_high"; 

^Process (process_id)  ^ "undefined"; 

effect 

Process (process_id) .mount^list (vol_id)  = "true"; 


Figure  5.  SSO  0-functions  (Concluded) 
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function  cannot  be  provided  at  the  kernel  interface  because  it 
violates  the  *-property.  Although  it  would  be  reasonable  to  provide 
this  function  to  all  users,  in  the  interest  of  maintaining  a simple 
specification  and  implementation  of  trusted  subjects  only  the  SSO  is 
allowed  to  execute  it. 

In  addition  to  checking  that  the  SSO  invoked  the  function,  the 
exceptions  ensure:  that  the  specified  segment  is  accessible  to  the  SSO 
at  its  current  access  level;  that  the  segment  is  not  the  root;  that  a 
positive  amount  of  quota  is  to  be  removed;  that  the  segment  is  not  a 
master  directory  (quota  cannot  be  removed  from  a master  directory); 
and  that  if  the  quota  will  remain  non-zero  it  will  cover  the  quota 
used. 


The  effect  of  **Reraove_upgraded_quota'*  is  to  reduce  the  quota  and 
the  quota  given  in  the  segment ''s  parent  by  the  specified  amount,  and 
to  increase  the  quota  field  of  the  segment's  parent's  parent. 

The  last  two  0-functions  are  used  by  the  SSO  in  processing  mount 
requests.  After  the  SSO  has  used  the  OV-function  "Read_mount_request” 
to  find  what  process  wants  what  logical  volume  mounted,  he  mounts  the 
appropriate  disk(s).  Once  he  has  done  the  mounting,  he  uses  the  func- 
tion ”Set__drive**  to  tell  the  kernel  what  drive (s)  the  logical  volume 
is  mounted  on.  He  then  uses  the  function  ”Set_nount__list"  to  notify 
the  requesting  process  that  the  volume  has  been  mounted. 

"Set_drive**  has  as  arguments  a drive  number  and  a logical  volume 
id.  The  exceptions  insure  that  the  caller  is  the  SSO  and  that  there 
is  no  process  that  currently  has  a volume  mounted  on  the  specified 
drive.  The  effect  is  to  save  the  name  of  the  volume  mounted  on  the 
specified  drive. 

**Set_mount__list"  has  as  arguments  the  name  of  the  process  that 
want  the  volume  mounted  and  the  name  of  the  volume.  The  exceptions 
check  that  the  caller  is  the  SSO  and  that  the  specified  process 
exists.  The  effect  is  to  set  the  mount  list  of  the  specified  process 
”true**  for  the  specified  volume. 

Design  Considerations 

As  has  been  noted,  the  users  of  the  functions  provided  by  this 
interface  are  trusted  to  preserve  the  integrity  of  the  system  and, 
therefore,  none  of  the  usual  kernel  access  control  checks  are  made. 
These  functions  are  not  required  to  correspond  to  the  mathematical 
model  of  security  because  they  represent  an  implementation  requirement 
that  is  not  addressed  by  the  model. 
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The  existence  of  an  SFEP  to  handle  terminal  I/O  is  not  reflected 
by  the  top-level  specification  of  trusted  subjects,  since  the  trusted 
subject  specification  describes  the  interface  provided  by  the  coopera- 
tive effort  of  the  SFEP  and  host.  Trusted  subjects  will  be  imple- 
mented as  unified  functions  through  appropriate  communication  between 
the  certified  software  on  both  machines.  Since  the  software  implemen- 
ting trusted  subjects,  in  both  machines  together,  must  be  verified  to 
implement  the  single  top-level  specification  given,  it  is  inappro- 
priate at  the  top  level  to  attempt  to  specify  separately  the  responsi- 
bilities allocated  to  each  machine. 


SSO  REVIEW 

The  SSO  fulfills  an  important  requirement:  interfacing  the  secu- 
rity kernel  with  the  external  environment.  Because  such  a requirement 
does  not  exist  in  the  current  Multics,  the  SSO  interface  does  not 
represent  an  incompatibility  with  current  Multics.  It  is  instead,  an 
addition  to  the  functionality  of  the  current  Multics  system. 


19 


SECTION  III 


RECONFIGURATION 


A Hultics  system  is  made  up  of  a number  of  different  types  of 
hardware  modules,  such  as  CPUs,  memory  modules,  and  I/O  modules. 

These  modules  must  be  interconnected  in  a very  precise  manner,  and 
once  connected,  all  the  modules  can  be  used  in  running  Multics. 
However,  modules  can  be  connected  but  not  used  in  running  Multics. 

The  operator  is  allowed  to  reconfigure  the  system  by  specifying  which 
of  the  connected  modules  should  be  used.  One  major  use  for  reconfigu- 
ration is  to  allow  modules  that  need  service  to  be  removed  from  system 
use  without  having  to  stop  Multics. 

This  section  deals  with  the  reconfiguration  of  certain  hardware 
modules  of  the  Multics  computer  system.  In  this  section  we  review  the 
current  Multics  reconfiguration  design.  Next,  we  present  the  kernel 
design  and  consider  compatibility  issues,  and  finally  we  give  a 
detailed  specification  of  the  reconfiguration  top-level  interface 
functions. 


THE  CURRENT  DESIGN 

The  current  Multics  reconfiguration  design  provides  operator 
functions  to  handle  the  reconfiguration  of  the  major  hardware  modules. 
Each  of  the  modules  will  be  identified  and  described.  Then,  the 
permissable  physical  and  logical  connections  of  the  modules  will  be 
discussed,  and  the  operator  reconfiguration  functions  dealing  with 
each  type  of  module  will  be  described. 

Major  Hardware  Modules 


The  hardware  modules  that  are  handled  by  reconfiguration  are 
described  briefly  below.  A more  detailed  description  is  given  in  the 
Multics  Reconfiguration  Program  Logic  Manual  [1]. 

A processor t or  CPU,  is  a major  processing  unit,  and  is  one  of 
three  types  of  modules  called  active  modules.  The  other  two  types  of 
active  modules,  the  lOM  and  the  bulk  store,  are  defined  below. 

An  lOM  is  an  input /output  controller.  It  is  another  of  the 
active  modules. 
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A bulk  store  is  the  third  kind  of  active  module.  It  provides 
auxiliary  memory  for  paging,  and  is  sometimes  referred  to  as  the 
paging  device. 

A system  controller  is  a non-active  hardware  module  that  inter- 
faces an  active  module  to  the  memory  of  the  configuration.  The  system 
controller  also  manages  system  interrupts  and  contains  the  system 
calendar  clock.  The  system  controller  is  often  referred  to  as  the 
controller.  Since  the  system  controller  interfaces  the  active  modules 
to  the  memory  and  hence  provides  memory  functions  to  its  users,  the 
system  controller  is  also  often  referred  to  as  a memory.  Since  this 
report  was  researched  a new  system  controller  was  announced  and  is 
being  offered  by  Honeywell.  This  new  controller,  often  referred  to  as 
the  **four  megaword  controller",  is  not  considered  in  this  report. 

Hardware  Module  Connections 


A port  is  a connection  point  for  two  hardware  modules.  A 
controller  port,  or  memory  port,  is  a port  on  a system  controller  for 
connection  to  an  active  module.  A processor  port,  or  CPU  port,  is  a 
port  on  a processor  for  connection  to  a system  controller. 

All  active  modules  (CPU,  lOM,  bulk  store)  are  connected  to  the 
system  via  the  system  controllers.  Each  active  module  is  connected  to 
every  system  controller  at  the  same  port. 

In  other  words,  if  a given  CPU  is  connected  to  port  1 on  one 
controller,  then  it  must  be  connected  to  port  1 on  the  other  control- 
lers as  well.  This  restriction  is  not  due  to  hardware,  but  to  soft- 
ware convention.  The  relationships  between  connected  memories  and 
CPUs  are  best  described  in  terms  of  the  notion  of  control. 

A control  processor  is  a processor  that  is  allowed  to  change  the 
port  control  and  interrupt  masking  values  of  a system  controller.  A 
processor  that  can  change  these  values  has  some  degree  of  control  over 
the  controller.  Each  system  controller  has  one  and  only  one  control 
processor,  although  a processor  can  be  a control  processor  for  more 
than  one  system  controller.  There  is  a switch  on  each  system 
controller  (the  Execute  Interrupt  Mask  Assignment,  or  EIIIA,  switch) 
that  defines  the  control  processor  for  that  controller. 

A CPU  is  usually  connected  to  several  controllers,  each  of  which 
connect  the  CPU  to  some  memory.  The  CPU  uses  a controller  to  access 
the  memory  the  controller  interfaces,  \lhen  a CPU  needs  some  other 
controller  function,  such  as  sending  interrupts,  there  is,  by  software 
convention,  a specific  controller  that  the  CPU  always  uses.  This 
controller  is  called  the  control  memory  for  the  CPU.  Each  memory  with 
its  EIMA  switch  selecting  a particular  CPU  is  potentially  a control 
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memory  for  that  CPU,  but  only  one  of  these  memories  is  actually  chosen 
as  the  control  memory.  Each  CPU  must  have  a control  memory,  and  a 
memory  cannot  be  a control  memory  for  more  than  one  CPU.  Therefore, 
there  must  be  at  least  as  many  memories  in  the  configuration  as  there 
are  CPUs. 

Figure  6 illustrates  a Multics  system  with  two  processors  and 
three  memories /system  controllers,  showing  the  control  processors  and 
control  memories.  CPU  A is  connected  to  each  memory  on  memory  port  7, 
and  CPU  B is  connected  on  memory  port  6.  Memory  A is  connected  to 
each  CPU  on  CPU  port  0,  Memory  B on  CPU  port  1,  and  Memory  C on  CPU 
port  2.  The  EIMA  switch  on  memory  A is  set  to  port  7 and  selects  CPU 
A as  control  processor.  The  EIMA  switch  on  memory  B is  set  to  port  7 
and  also  selects  CPU  A as  control  processor.  The  EIMA  switch  on 
memory  C is  set  to  port  6 and  selects  CPU  B as  control  processor.  CPU 
A is  control  processor  for  two  memories,  so  each  of  these  two  memories 
is  a potential  control  memory.  By  convention,  only  one  of  these  memo- 
ries is  used  as  control  memory,  and  memory  A has  been  chosen  in  this 
example.  CPU  B is  control  processor  for  only  one  memory,  so  that 
memory  is  control  memory  for  CPU  B. 

Now  that  we  have  presented  the  relevant  terminology,  we  can 
describe  the  operator  reconfiguration  functions  for  memories,  CPUs, 
and  bulk  store. 

Memory  Reconfiguration 

Memory  Reconfiguration  involves  adding  or  deleting  a system 
controller  (memory)  from  the  current  configuration.  The  names  of  all 
the  memories  in  the  system  must  be  specified  during  initialization, 
but  they  are  not  necessarily  configured  at  that  time.  The  memories 
that  exist  and  are  specified  at  initialization  time  may  be  added  or 
deleted  after  Initialization  using  operator  commands.  At  least  one 
memory  must  be  configured  at  initialization  time.  This  memory  is 
called  the  bootload  memory. 

The  operator  command  for  adding  a memory  specifies  the  name  of 
the  memory  to  be  added,  and  optionally  specifies  the  name  of  a partic- 
ular CPU  to  be  the  control  processor  for  the  new  memory.  The  operator 
is  prompted  to  perform  certain  actions  in  the  course  of  the  execution 
of  this  command. 

The  operator  command  for  deleting  a memory  specifies  the  name  of 
the  memory  to  be  deleted.  The  bootload  memory  cannot  be  deleted.  If 
the  memory  deleted  was  the  control  memory  for  some  CPU,  the  operator 
will  be  requested  to  make  switch  settings  on  the  memory  that  is  to  be 
the  new  control  memory  for  that  CPU. 
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Figure  6,  Hardware  Module  Connections 


Processor  Reconfiguration 


The  Multics  system  can  run  with  more  than  one  CPU,  but  when  it  is 
initialized,  only  one  CPU  (called  the  bootload  CPU)  is  running.  Any 
other  CPU^s  desired  must  be  added  by  using  the  reconfiguration  func- 
tions. Similarly,  system  shutdown  occurs  with  only  one  CPU  running, 
so  the  processor  reconfiguration  functions  are  a regular  part  of 
raultiple-CPU  system  operation. 

The  operator  function  for  adding  a CPU  specifies  the  name  of  the 
CPU,  the  system  controller  port  to  which  it  is  connected,  and  the  name 
of  its  control  memory.  Certain  operator  actions  are  necessary  during 
this  command,  and  the  operator  is  prompted  to  perform  them. 

The  operator  command  for  deleting  a CPU  specifies  the  name  of  the 
CPU  to  be  deleted.  The  operator  is  prompted  to  change  some  switches 
on  all  memories  that  are  controlled  by  the  CPU  being  deleted. 

Bulk  Store  Reconfiguration 

A bulk  store  is  used  as  a paging  device  in  the  Multics  system. 
Bulk  store  reconfiguration  is  different  from  other  types  of  reconfigu- 
rations in  that  it  deals  with  bulk  store  records  rather  than  with  the 
bulk  store  as  a whole.  There  is  only  one  bulk  store  in  a system,  and 
the  records  of  the  bulk  store  each  hold  one  page  of  memory.  The 
records  are  added  or  deleted  from  the  current  configuration  by  oper- 
ator commands. 

The  operator  command  for  adding  bulk  store  records  specifies  the 
first  record  to  be  added  and  the  number  of  records  to  be  added.  The 
command  is  allowed  if  the  specified  range  of  records  exists  in  the 
bulk  store.  Thus,  it  is  legal  to  specify  the  addition  of  a record 
that  is  already  configured,  making  it  easy  to  add  a large  block  of 
records  without  knowing  exactly  which  records  in  the  block  are  already 
configured. 

The  operator  command  for  deleting  bulk  store  records  specifies 
the  first  record  to  be  deleted  and  the  number  of  records  to  be 
deleted.  For  convenience,  it  is  legal  to  call  for  deletion  of  records 
that  are  already  deleted.  If  all  records  in  the  paging  device  are 
deleted,  then  the  device  may  be  disconnected  from  the  system  for 
repairs. 

It  should  be  noted  that  paging  device  record  deletion  is  also 
done  automatically  by  system  software  if  it  is  determined  that  a 
certain  record  is  bad  (i.e.,  causes  read  errors). 
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THE  KERNEL  DESIGN 


The  kernel  provides  reconfiguration  0-functions  that  support  all 
the  functions  currently  available  to  the  operator  to  perform  reconfig- 
uration. Hardware  reconfiguration  must  be  performed  by  the  kernel 
because  the  hardware  "belongs**  to  the  kernel  - the  kernel  uses"*  the 
hardware  to  create  objects  available  at  the  kernel  interface.  The 
data  manipulated  by  the  kernel  in  performing  reconfigurations  has  been 
assigned  an  access  level  of  **systemjiigh,  **  so  only  processes  with 
access  levels  of  **system_high**  may  use  the  reconfiguration  functions. 

A major  consideration  in  the  design  of  the  reconfiguration  func- 
tions is  the  handling  of  operator  interactions.  In  the  current 
design,  the  operator  is  prompted  to  perform  switch  settings  on 
controllers  and  processors  in  the  course  of  a reconfiguration.  This 
prompting  of  the  operator  is  undesirable  for  two  reasons.  First, 
since  kernel  functions  are  indivisible,  prompting  in  the  middle  of  a 
function  causes  specification  problems.  Second,  having  the  kernel 
rely  on  an  operator "'s  actions  to  work  properly  is  not  reliable.  The 
procedure  of  performing  a reconfiguration  with  operator  actions  is 
error-prone.  Therefore,  in  an  effort  to  simplify  the  kernel  and 
provide  for  more  error  free  operation,  we  have  attempted  to  remove  the 
necessities  of  operator  prompting. 

The  major  cause  of  operator  prompting  and  switch  settings  is  the 
Execute  Interrupt  Mask  Assignment  (EIMA)  switch.  As  mentioned  above, 
this  switch  is  used  to  specify  the  control  processor  for  each 
controller.  Each  controller  has  four  EIMA  switches,  each  of  which  may 
be  enabled  by  software.  In  the  current  design,  only  one  of  the 
switches  is  enabled,  so  the  setting  on  the  enabled  switch  determines 
the  control  processor  for  the  controller.  During  some  reconfigura- 
tions, the  setting  of  the  switch  must  be  changed  to  select  a different 
control  processor. 

An  example  of  the  need  for  changing  an  EUIA  switch  is  the  delete 
CPU  operator  function.  When  a CPU  that  is  the  control  processor  for 
some  system  controller  is  deleted,  then  the  EIMA  switch  on  that  system 
controller  must  be  changed  to  specify  some  other  CPU  as  a control 
processor.  In  the  current  design,  the  operator  is  told  which 
controller  to  set  the  switch  on,  and  what  the  switch  setting  should 
be.  Referring  to  our  previous  example  shown  in  Figure  6,  if  CPU  B is 
deleted,  the  EIMA  switch  on  memory  C (which  was  controlled  by  CPU  B), 
must  be  changed  to  select  port  7,  and  hence  CPU  A,  as  control  proc- 
essor. 

\ 

The  kernel  design  removes  the  requirement  for  operator  prompting 
and  switch  settings  in  two  ways.  First,  a non-hidden  V-function  that 
contains  Information  about  the  current  configuration  is  provided.  The 
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information  in  this  V-function  can  be  used  by  the  operating  system  to 
prompt  the  operator  before  the  reconfiguration  0-function  is  called. 
Second,  a new  convention  for  the  use  of  EIMA  switches  is  employed  by 
the  kernel.  Since  there  are  four  EIMA  switches  on  each  controller, 
each  switch  can  be  set  to  select  a different  processor  before  the 
system  is  initialized.  The  EIMA  switch  settings  are  the  same  for  each 
controller,  i.e.,  if  EIMA  switch  1 on  controller  A selects  processor 
B,  then  EIMA  switch  1 on  all  other  controllers  also  selects  processor 
B.  Once  the  switches  are  set  on  all  controllers,  and  the  kernel  is 
informed  of  the  setting  of  the  switches,  the  kernel  can  select  a 
control  processor  for  each  controller  by  enabling  only  the  appropriate 
EIMA  switch  in  software.  The  kernel  is  informed  at  initialization 
time  of  the  EIMA  switch  settings.  Only  processors  that  have  Ellik 
switches  selecting  them  may  be  configured,  so  this  convention  imposes 
the  restriction  that  only  four  CPUs  may  be  configured. 1 

Since  we  have  avoided  operator  interaction  problems,  the  kernel 
0-functions  can  perform  the  reconfigurations  present  in  the  current 
design  with  no  interruptions. 


COMPATIBILITY  WITH  THE  CURRENT  MULTICS 

Since  reconfiguration  functions  are  performed  only  by  operators, 
compatibility  is  not  as  great  an  issue  as  it  is  with  more  user 
oriented  subsystems.  The  reconfiguration  functions  provided  by  the 
kernel  roughly  correspond  to  the  operator  functions  provided  in  the 
current  design.  The  main  incompatibilities  are  in  the  area  of  oper- 
ator interaction,  and  have  been  discussed  in  the  previous  section. 


SPECIFICATION 

This  section  presents  a detailed  description  of  the  V-functions 
and  0-functions  that  define  the  top-level  specification  of  the  kernel 
reconfiguration  design. 

Data  Types,  Parameters,  and  Constants 

Figure  7 shows  the  data  types,  parameters,  and  constants  used  in 
the  reconfiguration  top-level  specification. 

There  are  five  non-standard  data  types  used  in  this  specifica- 
tion. Processor_j)ort_jiumber  is  the  port  number  of  a CPU  port,  to 


^This  restriction  does  not  seem  to  be  too  great,  since  newer  versions 
of  the  Multics  reconfiguration  software  impose  this  same  restriction. 
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type 

processor_jport_number  = integer  (0  to  max_processor_port ) ; 
memory_j>ort_number  = integer  (0  to  inax_controller_port ) ; 
processor^index  = integer  (0  to  max_processor__index) ; 
EIMA_switch_number : integer  (1  to  4); 
controller_data_type  = structure 

(exists:  boolean  /*  true  if  memory  exists  */ 
configured:  boolean  /*  true  if  mera  currently  configured  */ 
abs_wired:  boolean  /*  true  if  segment  can  contain  abs_wired 
segments  and  hence  cannot  be  deconfigured  */ 
control_processor : cpu_id  /*  control  processor  for  this  mem  */ 
controlled_proc:  cpu_jLd);  /*  processor  for  which  this 
controller  is  control  memory;  "undefined"  if  this 
memory  is  not  a control  memory  */ 
processor__data_type  » structure 

(configured:  boolean  /*  true  if  cpu  is  currently  configured  */ 
control_memory : processor_port_nuraber  /*  processor  port 
number  of  the  control  memory  for  this  cpu.  */ 
memory_port:  memory_port_number  /*  this  field  tells  to  which 
memory  port  the  processor  is  attached.  It  is  attached  to 
the  same  memory  port  on  each  system  controller.  */ 
EIMA_switch:  EIMA_switch_number ) ; /*  This  field  tells  which 

EIMA  (if  any)  points  to  this  cpu.  */ 


parameter 

controller:  processor_por^number^ 

record:  integer  (0  to 

count:  integer  (1  to  2'^°^  — _i); 

cpu_id : processor_index ; 

mera_port : nemory_j)ort_number ; 

control^jnera:  processor_port_nunber ; 

control_proc:  processor_index; 

icpu:  processor__index; 
imem:  processor_port_number ; 


constant 

max_processor_port : integer ; 
max_controller_j)or t : integer ; 
max_j)rocessor_index:  integer ; 


Figure  7.  Reconfiguration  Data  Types,  Parameters,  and  Constants 
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which  a system  controller  (memory)  is  attached.  Memory_port_number  is 
the  system  controller  (memory)  port  number  to  which  a CPU,  lOM,  or 
bulk  store  controller  is  attached.  Processor__index  is  a name  for  a 
CPU. 


Controller__data__type  is  a structure  that  contains  data  about  all 
the  possible  controllers  or  memories  in  the  system.  Exists  is  true  if 
the  memory  exists,  as  specified  at  initialization  time.  Configured  is 
true  if  the  memory  is  configured.  Abs_wired  is  true  if  the  memory 
contains  abs_wired  segments. 2 Controljrocessor  specifies  the  control 
CPU  for  this  memory,  and  controlled_j)roc  specifies  the  CPU  for  which 
this  is  control  memory. 

Processor_data_type  is  a structure  that  contains  data  about  all 
the  possible  CPUs  in  the  system.  Configured  is  true  if  the  CPU  is 
configured.  Control_jaemory  specifies  the  control  memory  for  this  CPU. 
Memory_j>ort  specifies  the  memory  port  (on  all  memories)  to  which  this 
CPU  is  attached.  EIIlA_switch  is  undefined  if  this  CPU  is  not  speci- 
fied on  any  EIllA  switches;  otherwise,  it  is  the  number  of  the  EIIiA 
switch  on  which  the  CPU  is  selected. 

The  parameter  section  defines  the  data  types  of  the  arguments 
used  in  the  specification.  Controller  is  a processorjort^number , and 
serves  to  identify  a specific  system  controller  (memory).  Record  and 
count  are  used  to  specify  a paging  device  record  number  and  number  of 
records,  respectively,  for  the  paging  device  reconfiguration  func- 
tions. Cpu_id  is  a processor_index,  and  serves  to  identify  a specific 
CPU.  Memjort  is  a memory_port_number  for  some  CPU.  Control_mem  is 
the  processor_port_number  of  some  control  memory,  and  control_proc  is 
the  name  of  some  control  processor.  Icpu  and  iraem  are  used  as  quanti- 
fied variables  in  the  specification. 

The  constant  section  lists  certain  constant  arguments  whose 
actual  value  is  irrelevant  to  the  security  of  the  top  level.  The 
constants  listed  are  the  maximum  number  of  processor  ports,  controller 
ports,  and  CPU's,  respectively. 

Reconfiguration  V-functlons 

Figure  8 contains  the  hidden  and  non-hidden  V-functions  in  the 
specification.  The  hidden  V-functions,  listed  first,  serve  as  data 
bases  internal  to  the  kernel  and  not  available  at  the  kernel  inter- 
face. The  first  four  hidden  V-functions  contain  data  about  the  major 


2Abs_wired  segments  are  segments  that  are  permanently  core  resident. 

If  a memory  contains  any  abs_jwired  segments  then  it  cannot  be  deleted. 
Normally  only  the  bootload  memory  contains  abs_wlred  segments. 
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Hidden_y_f unction  Controller_data(controller ) ; controller_data_type; 


Hidden_y_f unction  Processor_data(cpu_id) : processor_data_type; 


Uidden_V_f unction  IOM_memory_port : ineraory_port_number ; 

/*  This  function  tells  to  which  memory  port  the  lOM  is  attached. 
It  is  attached  to  the  same  memory  port  on  each  controller  */ 

Hidden__y_f unction  Pd_size:  integer;  /*  # of  pages  on  paging  device  */ 
size  of  paging  device  */ 


Hidden_y_f  unction  Nprocessors;  integer  (1  to  max_jprocessor_index-l*l)  ; 


Hidden_V_f unction  Nmemories:  integer (1  to  raax_processor_j)ort+l) ; 


/*  Interface  (non-hidden,  derived)  V-function  */ 


V_function  Configuration:  structure 

(controllers  (controller) : controller__data_type 
processors (cpu_id) : processor_data_type) ; 

exception 

Cur.access_level  “systerajhigh"; 
derivation 

controllers  = Controller_data; 
processors  * Processor_data; 


Figure  8.  Reconfiguration  V-functions 
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hardware  modules.  Controller_data  contains  data  about  all  possible 
system  controllers  (memories)  in  the  system,  as  defined  by 
controller__data_type.  Similarly,  Processor_data  contains  data  about 
the  CPUs  in  the  system.  IOM_jnenory_port  is  the  memory  (system 
controller)  port  to  which  the  lOM  is  attached.  This  value  is  set  at 
initialization  time  and  does  not  change.  Pd__size  is  the  size,  in 
pages,  of  the  paging  device.  This  value  is  set  at  initialization  time 
and  does  not  change. 

The  last  two  hidden  V-f unctions,  Nprocessors  and  Nmemories,  are 
counts  of  the  number  of  CPUs  and  memories  currently  in  the  configura- 
tion, respectively. 

There  is  one  non-hidden  interface  V-function  in  this  specifica- 
tion, which  provides  information  about  the  current  configuration  for 
use  by  uncertified  software  executing  at  the  operator's  request.  This 
V-function,  called  Configuration,  is  derived  from  Controller_data  and 
Processor_data. 

Memory  Reconfiguration  Q-f unctions 

Figure  9 shows  the  functions  Add_jnemory  and  Delete_memory. 
Add_raemory  takes  as  arguments  the  name  (processor_port_number)  of  the 
controller  (memory)  to  be  added,  and  ah  argument  to  specify  the  CPU  to 
be  used  as  control  processor  for  this  memory.  The  function  requests 
that  the  specified  memory  be  added  with  the  specified  CPU  as  control 
processor. 

The  exceptions  for  Add_memory  make  sure  that  the  current  access 
level  is  ’*systemjhigh”,  that  the  specified  controller  exists  and  is 
not  already  configured,  and  that  the  control  processor  is  configured. 

The  effects  of  the  function  include  the  following.  Configured  is 
set  for  the  specified  memory.  Abs_jwired  is  set  to  false  for  the  spec- 
ified memory,  because  it  will  contain  not  abs_wired  segments. 
Control_j)rocessor  is  set  from  the  specified  second  argument,  and  the 
count  of  configured  memories  is  incremented. 

Delete  memory  takes  two  arguments  also.  The  first  argument  is 
the  name  of  the  memory  (controller)  to  be  deleted.  The  second  argu- 
ment is  the  name  of  another  memory  to  be  used  as  control  memory  for 
any  CPUs  for  which  the  deleted  memory  was  a control  memory.  Each  CPU 
must  have  a control  memory.  The  second  argument  can  be  left  undefined 
if  this  deleted  memory  was  not  a control  memory.  Uncertified  software 
can  determine  from  the  V-function  Configuration  controllers  whether  or 
not  the  memory  to  be  deleted  was  a control  memory.  If  it  was,  the 
second  argument  must  be  supplied. 
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/*  Memory  (system  controller)  Reconfiguration  0-functions  */ 


0_JE unction  Add_memory  (controller , cont roljroc ) 
exception 

Cur.access_level  “systemjtiigh"; 

^Controller^data (controller ) . exists ; 

Controller__data  (controller) . configured; 

^Processor_data  (control__proc  ) • configured ; 

effect 

Controller__data  (controller)  .configured  = **true*’; 
Controller__data (controller ).abs_wired  * "false”; 
Controller__data (controller) .control^processor  * control__proc; 
Controller_data (controller) .controlled_j)roc  » "undefined"; 
Nmemories  » 'Nmemories  + 1; 


0__f unction  Delete_j[neraory (controller,  control_jnem) 
let 

controlled_j>roc  * Controller_data (controller)  .controlled_j)roc; 
control_memory  * Processor_data(controlled_j>roc)  .control_jnemory 

exception 

Cur.access__level  "systen_high"; 

Nmemories  = Nprocessors;  /*  Can^t  delete  any  more  memories  */ 
^Controller__data  (controller)  .configured; 

Controller_jiata  (controller ) . abs_wired ; 
controlled_proc  "undefined"  & 

(^Controller_jdata(control_mem)  .configured  | 
Controller_data(control_mem) .controlled__proc^*"undef ined") ; 

effect 

Controller__data  (controller)  .configured  = "false"; 

Nmemories  * 'Nmemories  -1; 
if  controlled__proc  "undefined" 
then  control_memory  « control_mem; 

Controller_jdata(control_jiiem)  .controlled_j)roc  « 
cont  rolled_j)roc ; 

end; 


Figure  9.  Memory  Reconfiguration  0-functions 
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The  exceptions  for  Delete_memory  check  that  the  current  access 
level  is  "systeinjiigh, " and  that  the  number  of  memories  configured  is 
not  equal  to  the  number  of  CPUs  configured.  If  these  counts  are 
equal,  there  will  not  be  enough  memories  for  control  memories  if  a 
memory  is  deleted.  There  must  always  be  at  least  as  many  memories  as 
there  are  CPUs  in  the  configuration. 

The  exceptions  also  check  that  the  memory  is  not  abs_wired. 
Finally,  if  the  control_mem  argument  is  needed,  then  control_jnem  must 
be  configured  and  must  not  be  a control  memory  already. 

The  effects  of  Delete^memory  are  as  follows.  The  configured  flag 
is  set  to  false  for  the  indicated  memory.  The  count  of  the  number  of 
memories  is  decremented.  If  the  deleted  memory  was  controlling  some 
CPU,  then  control_raem  (the  second  argument)  is  made  the  control  memory 
for  that  CPU. 

Paging  Device  Reconfiguration  Q-functlons 

Figure  10  contains  the  two  paging  device  (bulk  store)  reconfigu- 
ration 0-functions.  As  mentioned  earlier,  bulk  store  reconfiguration 
deals  with  bulk  store  records  rather  than  with  the  bulk  store  itself. 

The  two  functions  each  take  as  arguments  the  number  of  the  first 
record  to  be  added  or  deleted,  and  the  number  of  records  to  be  added 
or  deleted.  The  exceptions  for  both  functions  are  the  same:  to  check 
that  the  current  access  level  is  ”system_Jiigh",  and  that  the  range  of 
records  specified  lies  within  the  bulk  store. 

These  functions  have  no  visible  effects  at  the  interface  level. 

In  other  words,  a call  to  these  functions  has  no  effect  on  the  results 
of  any  future  calls,  because  it  is  legal  to  add  already  configured 
records  and  to  delete  already  deleted  records.  The  only  possible 
top-level  effect  is  on  the  speed  of  the  system,  but  time  is  not 
observable  at  the  top  level. 

CPU  Reconfiguration  0-functions 

Figure  11  contains  the  CPU  reconfiguration  0-functions,  Add_cpu 
and  Delete_cpu. 

Add_cpu  requires  three  arguments:  the  name  of  the  CPU  to  be 
added,  the  control  memory  for  that  CPU,  and  the  memory  port  to  which 
that  CPU  is  attached.  The  exceptions  for  the  function  make  sure  that: 
the  current  access  level  is  "systemjhigh”,  the  specified  CPU  is  not 
already  configured,  the  specified  control  memory  is  configured  and  is 
not  already  a control  memory,  and  that  the  specified  memory  port  is 
not  already  being  used  for  some  processor  or  for  the  lOM. 
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/*  Paging  Device  Record  Reconfiguration  0-functions  */ 


0_f unction  Add_j)d_records (record,  count) 
exception 

Cur.access_level  "systerajiigh”; 
record+count-1  > Pd^jsize; 


0_f unction  Delete_j)d_records (record,  count) 
exception 

Cur.access_level  **systemjiigh"; 
record+count-1  > Pd^size; 


Figure  10.  Paging  Device  Reconfiguration  0-functions 
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/*  Processor  (CPU)  Reconfiguration  0-functions  */ 


0__f unction  Add__cpu(cpu_id,  control_niem,  men_j)ort) 
exception 

Cur,access_level  **system_Jiigh"; 

Processor__da  ta  ( cpu_id ) . conf  igur  ed ; 

Processor_data(cpu_id)  .EIMA_switch  * "undefined**; 
""Controller__da ta  (cont rol^inem)  • conf  igured ; 

Controller__data(control_jneni)  • controlled_j)roc  **undef  ined**; 
(ficpu)  (Processor__data  (icpu)  •memory_j)ort  * mem_port); 
IOM__meraory__port  = neni_j)ort; 
effect 

Processor__data(cpu__id) . conf  igured  = **true**; 

Processor__data  (cpu_id) . control_memory  = control_iaem; 
Processor_data(cpu_id)  .meraory_port  * mera_j)ort; 
Controller__data(control_jneia).controlled_j)roc  = cpu_id; 
Nprocessors  = 'Nprocessors  -h  1; 


0__f unction  Delete_cpu(cpu__id,  control_proc) 
let 

control_meinory  = Processor__data(cpu_id)  •control_jaeraory ; 
exception 

Cur.access_level  **systein_high**; 

Nprocessors  * 1;  /*  can't  delete  last  cpu  */ 
^Processor_jdata(cpu__id)  .configured; 

"'Processor^data  (control_j)roc) . configured; 

effect 

Processor__data(cpu_id)  .conf  igured  = **false**; 

Nprocessors  * 'Nprocessors  -1; 

Controller__data(control_niemory)  .controlled__proc  = **undef  ined**; 
(Vimeia)  if  Controller_jdata(iinem).control_processor  * cpu__id 
then  Controller_jiata(imem)  .control_j)rocessor  = control__proc; 
end; 


Figure  11.  CPU  Reconfiguration  0-functions 
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The  effects  of  Add_cpu  are  as  follows.  The  configured  flag  is 
set  for  the  specified  CPU,  and  the  control^iaemory  and  memory_port 
fields  are  filled  in.  Also,  the  controlled_j>roc  field  on  the  speci- 
fied control  memory  is  set  to  the  CPU  being  added.  Finally,  the 
number  of  processors  configured  is  incremented. 

The  0-function  Delete__cpu  takes  two  arguments.  The  first  is  the 
name  of  the  CPU  to  be  deleted.  ^ The  second  argument  is  the  name  of 
another  CPU  to  be  used  as  control  processor  for  any  memories  for  which 
the  deleted  CPU  was  control  processor.  This  argument  can  be  "unde- 
fined** if  the  deleted  CPU  was  not  a control  processor. 

The  exceptions  for  Delete^cpu  insure  that:  the  current  access 
level  is  **systemjiigh**,  there  is  more  than  one  CPU  configured,  the 
specified  CPU  is  configured,  and  that  if  needed,  the  specified 
control_j)roc  is  configured. 

The  effect  of  Delete__cpu  is  as  follows.  Configured  is  set  to 
false  for  the  specified  CPU.  The  number  of  processors  is  decremented. 
The  controlled_proc  field  for  the  memory  that  was  controlling  the  CPU 
is  set  to  **undef ined**.  Each  memory  that  was  controlled  by  the  speci- 
fied CPU  is  set  to  be  controlled  by  control_jproc. 


RECONFIGURATION  REVIEW 

In  this  section  we  have  described  the  kernel  interface  functions 
dealing  with  the  reconfiguration  of  the  various  hardware  modules  of 
the  llultics  system.  The  current  design  of  the  hardware  reconfigura- 
tion operator  functions  has  been  described,  and  we  have  seen  that  the 
kernel  functions  are  basically  compatible.  The  main  area  of  incompat- 
ibility, that  of  operator  interaction  during  reconfigurations,  has  been 
pointed  out.  We  have  also  described  the  detailed  specification  of  the 
kernel  functions  for  memory  (system  controller)  reconfiguration, 
paging  device  (bulk  store)  reconfiguration,  and  CPU  (processor)  recon- 
figuration. 
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SECTION  IV 


INITIALIZATION 


Initialization  is  the  process  through  which  Multics  is  loaded 
into  the  computer  and  started  running  in  its  normal  mode.  This 
section  discusses  the  problems  involved  with  Multics  system  initiali- 
zation. Initialization,  very  important  to  the  security  of  the  kernel, 
puts  the  kernel  into  a secure  state,  and  the  kernel  0-functions  map 
the  kernel  from  one  secure  state  into  another.  Once  the  system  is  in 
a secure  state,  it  will  stay  secure. 

In  this  section  we  shall  discuss  briefly  how  initialization  is 
accomplished  in  the  current  Multics,  then  we  will  discuss  initializa- 
tion of  the  security  kernel.  Compatibility  issues  with  the  current 
Multics  will  be  considered,  and  the  specifications  dealing  with 
initialization  will  be  presented. 


THE  CURRENT  DESIGN 

As  it  exists  today,  initialization  of  a Multics  system  is  very 
complex  and  is  difficult  to  verify.  The  initialization  process  is  not 
well  modularized  and  is  extremely  hard  to  understand  and  modify.  The 
complexity  of  the  design  and  coding  makes  verification  infeasible. 

The  information  necessary  to  initialize  the  Multics  system 
resides  in  two  places,  the  Multics  System  Tape  (MST),  and  the  CONFIG 
deck.  The  MST  contains  the  programs  and  data  that  must  be  loaded  to 
start  Multics  in  any  configuration,  at  any  installation.  The  informa- 
tion on  the  MST  is  installation  independent.  The  CONFIG  deck  contains 
the  installation  dependent  data  that  is  read  by  Multics  to  initialize 
itself  in  a particular  configuration. 

To  initialize  the  system,  the  operator  issues  commands  to  the 
Bootload  Operating  System  (BOS)  [2].  At  this  time  the  operator  speci- 
fies whether  this  initialization  is  to  be  a warm  start  or  a cold 
start.  A warm  start  (the  most  common),  means  the  initial  storage 
hierarchy  is  to  be  the  one  present  at  the  last  system  shutdown.  A 
cold  start  means  the  storage  hierarchy  is  to  be  recreated. 

At  the  command  of  the  operator,  BOS  puts  the  CONFIG  deck  in  a 
fixed  place  in  memory  and  starts  reading  the  MST.  The  segments  on  the 
MST  are  organized  into  three  collections  of  data.  Each  collection, 
when  loaded,  initializes  itself  to  provide  a richer  environment  for 
the  next  collection  to  run  in,  and  then  reads  in  the  next  collection. 
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Through  this  reading  and  initializing  of  collections,  the  standard 
ring  0 environment  is  eventually  achieved.  A more  detailed  descrip- 
tion of  the  initialization  procedure  can  be  found  in  [3]. 

One  of  the  problems  with  this  initialization  scheme  is  that  it  is 
never  really  clear  v/hat  environment  a given  initialization  program 
runs  in.  The  number  of  different  environments  makes  verification 
infeasible. 


THE  KERNEL  DESIGN 

The  initialization  of  a kernel  based  Multics  system  is  slightly 
different  from  that  of  the  current  Multics  system,  and  consists  of  two 
parts;  initialization  of  the  kernel,  and  initialization  of  the  rest  of 
the  operating  system.  From  the  standpoint  of  security,  we  are 
concerned  only  with  the  initialization  of  the  kernel.  Once  the  kernel 
is  securely  initialized,  the  remainder  of  initialization  may  run  with 
unverified  code. 

The  scenario  for  initialization  of  a kernel  based  Multics  system 
is  as  follows.  First,  the  Bootload  Operating  System  (BOS)  will  be 
retained.  It  is  not  known  at  this  time  how  much  of  BOS  can  remain 
unverified,  but  it  is  certain  that  part  of  BOS  must  be  verified, 
specifically,  the  portion  that  handles  the  CONFIG  deck  and  the  portion 
that  loads  the  kernel  tape. 

To  start  initialization,  BOS  loads  the  kernel  from  a protected 
tape^  and  initializes  the  kernel.  This  loading,  initialization,  and 
starting  of  the  kernel  may  be  accomplished  in  several  ways.  One  might 
be  to  save  a core  image  of  the  kernel  after  it  has  initialized  itself, 
and  simply  load  and  start  this  (already  initialized)  core  image.  Once 
loaded  and  started  at  the  appropriate  point,  the  kernel  would  then 
proceed  to  load  and  initialize  the  rest  of  the  operating  system  from 
another  tape,  similar  to  the  MST  in  the  current  design.  From  the 
standpoint  of  security,  we  are  mainly  concerned  with  the  loading  and 
initializing  of  the  kernel.  The  operating  system  resides  on  two  tapes 
because  one  tape,  which  contains  the  kernel,  must  be  protected  and 
handled  with  special  procedures.  The  same  restrictions  do  not  apply 
to  the  tape  which  contains  the  rest  of  the  operating  system. 

The  kernel  representation  will  be  placed  on  the  protected  tape  so 
that  when  loaded  into  core  and  started  in  a specific  place  it  will  be 
secure.  Thus,  the  kernel  must  be  completely  initialized  before  it  is 


^While  tape  is  currently  used  as  a storage  medium  for  system  software, 
we  do  not  imply  the  kernel  storage  medium  is  restricted  to  tape. 
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placed  on  the  protected  tape.  Once  loaded,  the  kernel  will  be  config- 
ured to  the  hardware  using  initialization  configuration  functions  and 
information  from  the  CONFIG  deck.  The  CONFIG  deck  in  the  kernel 
design  will  be  similar  to  the  CONFIG  deck  in  the  current  design,  but 
will  be  expanded  to  contain  some  security-sensitive  information. 
Processing  the  CONFIG  deck  and  calling  the  initialization  configura- 
tion functions  must  be  done  by  verified  code. 

To  verify  that  the  system  is  initialized  securely,  we  must  verify 
that  the  kernel  representation  on  the  protected  tape  is  correct.  This 
verification  may  be  performed  in  two  ways.  First,  we  may  inspect  the 
contents  of  the  tape.  This  need  be  done  only  once  for  each  copy  of 
the  system.  Second,  we  can  generate  the  tape  with  verified  software. 
It  is  unclear  which  method  is  preferable. 

V-function  Initialization 


Since  the  initial  state  of  the  kernel  must  be  secure,  we  must 
have  some  way  to  specify  the  initial  secure  state  in  terms  of  the 
V-functions  that  define  the  kernel.  We  must  therefore  specify  the 
initial  values  of  all  non-derived  V-functions. 

Specifying  the  initial  values  of  the  V-functions  will  define,  for 
example,  the  initial  hardware  configuration  and  the  initial  state  of 
the  system. 

Initialization  Reconfiguration  Functions 

The  initial  secure  kernel,  as  loaded  from  the  protected  tape,  is 
a functional  kernel,  but  will  not  reflect  the  hardware  and  software  on 
which  the  system  is  to  run.  VJe  must  provide  0-functions  to  modify  the 
state  of  the  kernel  in  a secure  manner.  The  functions  dealing  with 
the  hardware  are  described  in  the  section  on  reconfiguration.  There 
are  other  functions,  however,  that  will  be  desirable. 

Additional  functions  may  be  required  to  deal  with  changing  the 
size  and/or  number  of  kernel  data  bases  and  to  assimilate  the  data 
found  on  the  CONFIG  deck  into  the  kernel  configuration.  Not  all  of 
the  desirable  functions  have  been  identified  yet,  but  some  are 
included  in  the  specification. 

Lower  Level  Initialization 


The  functions  shown  in  this  specification  are  concerned  only  with 
the  initialization  of  top  level  V-functions.  There  is  some  informa- 
tion that  must  be  supplied  at  initialization  time  that  is  supplied  to 
lower  levels  of  the  kernel,  such  as  physical  device  addresses.  This 
information  is  not  treated  in  this  specification. 
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COMPATIBILITY  WITH  THE  CURRENT  MULTICS 


The  kernel  initialization  scheme  is  not  compatible  with  the 
current  scheme  because  only  part  of  the  total  initialization  process 
will  be  verified.  Multics  initialization  as  a whole  is  different, 
because  of  the  existence  of  two  system  tapes,  one  protected,  and  one 
not.  Compatibility  is  not  as  much  of  an  issue  with  initialization  as 
it  is  with  other,  more  user-oriented  subsystems.  An  incompatible 
initialization  interface  effects  only  the  operators,  not  the  users. 

The  real  compatibility  issues,  however,  are  concerned  with  the 
generality  and  installation  independence  of  the  information  on  the  two 
tapes.  The  current  MST  is  installation  independent.  The  current 
initialization  process  is  unstructured  and  ad  hoc.  The  new  initiali- 
zation technique  provides  more  structuring,  and  provides  a standard 
(kernel)  environment  in  which  most  of  initialization  can  run.  The 
standard  environment  is  achieved  by  binding  together  most  (if  not  all) 
of  the  kernel  at  the  protected  tape  generation  tine,  instead  of  at  run 
time.  It  is  possible  that  pre-binding  may  cause  a slight  loss  of 
generality  of  the  kernel  tape,  the  extent  of  which  is  not  known  at 
this  time. 


SPECIFICATION 

We  will  now  describe  in  detail  the  specification  of  the  top  level 
of  initialization.  The  initialization  specification  consists  of 
parameter  and  constant  definitions,  an  0-function  to  initialize  the 
V-f unctions  in  the  top  level,  and  some  initialization  configuration 
0-functions. 

The  initialization  0-functions  are  trusted  functions  (trusted 
subjects),  because  the  security  of  their  operation  depends  on  the 
validity  of  their  arguments.  In  other  words,  for  secure  operation, 
the  arguments  must  be  specified  correctly.  This  restriction  should 
not  be  a problem,  however,  because  the  arguments  required  by  these 
functions  are  supplied  by  users  who  are  trusted  to  perform  correctly. 
The  interface  between  these  functions  and  their  users  is  like  the 
interface  described  in  the  previous  section  on  the  SSO. 

Initialization  Parameters  and  Constants 


Figure  12  shows  the  parameters  and  constants  defined  for  initial- 
ization. The  first  group  of  parameters  defines  the  types  of  the 
arguments  to  the  0-function  ”Initialize_top_level. **  The  second  group 
of  parameters  defines  the  types  of  the  arguments  for  the  initializa- 
tion configuration  0-functions. 
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/*  Initialization  parameters  */ 


parameter 

cold__start:  boolean; 

IOM_p  o r t : memo  r y_p  o r t_numb  er ; 
bootload_cpu:  processor^index; 
bootload_cpu_jmemory_port : memory_port_number ; 
bootload_memory : processor_port_number ; 
idevice_id : uid_type ; 
lent ry : ent ry_ty pe ; 
iprocess_id : uid_type ; 
iuid:  uid_type; 
paging_device_size:  integer; 

device_max_al,  device_jnin_al,  device_access_level:  access_level_type; 
vol_id:  uid_type; 

vol_jaccess_level:  access_level_type; 
vol_#_of__packs,  voljuota:  integer; 


/*  Initialization  constants  */ 


constant 

SSO:  uid_type; 
initializer : uid__type ; 

initializer__process_data : process_type ; 
initial_interpreter_data:  interpreter_data_type; 
root_branch:  branch^type; 


Figure  12.  Initialization  Parameters  and  Constants 
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Five  constants  are  defined  for  this  specification.  **SSO"  is  the 
unique  identification  of  the  System  Security  Officer  (SSO)  terminal, 
"initializer"  is  the  unique  ID  of  the  initializer  process,  and 
"initializer_j)rocess_data"  is  the  initial  data  about  the  initializer 
process.  Data  about  the  initial  state  of  the  interpreter  is  contained 
in  "initial_interpreter_data".  The  constant  "root_branch"  is  the 
branch  that  describes  the  root,  and  is  stored  in  the  root. 

Initialize  Top  Level  0-function 

Figure  13  illustrates  the  0-function  that  initializes  all  non-de- 
rived  V-functions  in  the  top  level  specification.  Initializing  the 
non-derived  V-functions  also  initializes  the  derived  V-functions, 
since  they  are  derived  from  non-derived  V-functions.  The  effect 
section  for  this  function  lists  the  effects  pertaining  to  each 
subsystem  in  the  specification.  The  arguments  to  Initialize_top_level 
will  be  discussed  along  with  the  subsystem  that  uses  them. 

The  effects  pertaining  to  reconfiguration  use  the  first  nine 
arguments.  These  arguments  must  be  specified  correctly  for  the  system 
to  run  correctly  and  for  the  reconfiguration  functions  to  work 
securely  and  correctly.  "IOM_j)ort"  is  the  memory  port  number  of  the 
lOM.  "Bootload_CPU"  is  the  processor  index  of  the  running  CPU. 
"Bootload_CPU_memory_j)ort"  is  the  memory  port  to  which  this  CPU  is 
attached.  "Bootload_memory"  is  the  number  of  the  processor  port  to 
which  the  boot load  memory  is  attached.  "EIMA_switch_"  1 to  4 are  the 
processor  indices  of  the  CPUs  selected  by  the  four  EIMA  switches. 
"Paging  device  size"  is  the  number  of  records  in  the  paging  device. 

The  V-functions  in  the  reconfiguration  specification  are  initialized 
to  reflect  the  hardware  base  of  the  system  as  specified  by  these  five 
arguments. 

"IOM_memory_j)ort"  saves  the  memory  port  number  of  the  lOM  for 
future  error  checking.  "Processor_data"  is  initialized  to  reflect  the 
current  CPU  configuration.  Only  the  bootload  CPU  is  configured.  The 
control  memory  for  the  bootload  CPU  is  the  bootload  memory,  as  speci- 
fied by  the  0-function  argument.  The  memory  port  to  which  the  boot- 
load CPU  is  attached  is  set  from  "bootload_CPU_jnemory_port".  The 
"EIMA_switch"  field  for  each  processor  is  set  to  the  number  of  the 
EIMA  switch  selecting  that  processor.  If  no  EIMA  switch  is  selecting 
the  processor,  then  the  "EIMA_switch"  field  is  undefined. 

"Controller_data"  is  set  to  reflect  the  initial  set  of  memories. 
During  this  phase  of  initialization,  only  the  bootload  memory  is 
considered  to  exist.  The  existence  of  other  memories  is  made  known 
with  the  "Def ine_system_controller"  0-function  (described  below).  The 
bootload  memory  is  configured  and  contains  abs_wired  segments.  The 
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/*  Initialization  0-functions  */ 


0_f unction  Initialize_top_level  (lOMjort,  bootload__cpu, 
bootload_cpu_memory_port , bootload_memory , EIllA_switch_l , 
EIiIA_switch_2,  EIIiA_switch_3,  EIMA_switch_4,  paging_device_size, 
cold_start ) 

effect 


/*  Reconfiguration  Initialization  effects  */ 

I011_jnemory_port  = IOM_port; 

Processor__data(bootload_cpu),  configured  = "true”; 

Processor  (bootload_cpu).control_jnemory  = bootload_jnemory ; 

Processor_data(bootload_cpu)  .memory_port  » bootload_cpu_jiieraory_port ; 

(Vicpu?^bootload_cpu)  Processor_data(icpu)  .configured  « "false"; 

(Vicpu)  if  icpu«EIMA_switch_l  then  Processor_data(icpu) .EIMA_switch=l 
else  if  icpu=EIl^_switch_2  then  Processor_data(icpu)  .ElHA__switch*2 
else  if  icpu=EIMA__switch_3  then  Processor_data(icpu)  .EIMA_switch“3 
else  if  icpu=EIMA_switch_4  then  Processor_data(icpu) .EIMA_switch*4 
else  Processor_data(icpu) .EIMA_switch  = "undefined"; 
end; 

Controller_data(bootload_meinory ).  exists  = "true"; 

Controller__data(bootload_memory). configured  * "true"; 

Controller_data(bootload_jnemory) .abs_wired  « "true"; 

Controller_data(bootload_jnemory)  .controlled^jproc  » bootload_cpu; 

Controller_data(bootload_meraory) .control_processor  **  bootload_cpu; 

(Vimemii^bootloadjmemory)  Controller__data(imera)  .exists  » "false"; 

Nprocessors  = 1; 

Nmemories  * 1 ; 

Pd_size  « paging  device  size; 

/*  Interpreter  Initialization  effects  */ 

lnterpreter__data  « initial__interpreter_data; 


/*.SSO  Initiialization  effects  */ 
lIount_request  = "undefined"; 


Figure  13.  Initialize_top_level  0-function 


42 


External  I/O  initialization  effects  */ 


Device (SSO ) •Taax_al  * **systeia_high**; 

Device  (SSO  ) •min^^al  * **system_low**; 

Device  (SSO ) .access_level  » **systei!i_high**; 

Device  (SSO)  .owner  * **undef  ined"; 

Device(SSO) . status  = **undef  ined”; 

Device(SSO) .buf f er  « ''undefined”; 

(Videvice_id  4 SSO) (Device (idevice_id)  « "undefined”); 


/*  Process  control  initialization  effects  */ 

Cur_process  « initializer; 

Process (initializer)  * initializer_j)rocess_data; 

(Vlprocess_^id  4 initializer) (Process (iprocess_id)  * "undefined”); 


^ /*  Common  initialization  effects  */ 

Audit_log  * "undefined”; 


/*  Storage  Control  initialization  effects  */ 

Drive  = "undefined”; 
if  cold_start  then 

Directory (rootjuid,  "root")  « root_branch; 

(Vientry  4 "root”) (Directory (root_uid,  ientry)  « "undefined”); 
(Viuid  4 rootjuld)  (Vientry) 

(Directory (iuid,  ientry)  * "undefined”); 

LVRF  * "undefined”; 
end; 

/*  If  this  is  a cold  start,  we  must  initialize  with  an  empty  tree, 
otherwise,  the  tree  is  already  there,  having  been  initialized  when 
created.  */ 


Figure  13.  Initialize_top__level  0-function  (Concluded) 
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control  processor  for  the  bootload  memory  is  the  bootload  CPU,  and  the 
CPU  controlled  by  the  bootload  memory  is  the  bootload  CPU. 

The  remainder  of  reconfiguration  initialization  sets  the  current 
number  of  processors  to  one,  the  current  number  of  memories  to  one, 
and  the  size  of  the  paging  device  to  **paging__device_size". 

The  initialization  of  the  interpreter  involves  setting  the 
initial  value  of  **Interpreter_data"  to  , **initial_interpreter_data. " 

The  SSO  is  initialized  by  setting  the  list  of  mount  requests  to 
"undefined.  ** 

The  initialization  of  external  I/O  defines  the  initial  device 
configuration.  "Device"  contains  information  about  one  terminal,  the 
SSO  terminal.  Information  about  other  terminals  is  not  stored  in 
"Device",  because  they  are  considered  SFEP  devices,  whereas  the  SSO 
terminal  is  considered  a kernel  device.  The  access  level  in  the  SSO 
terminal  is  system  high.  The  SSO  is  the  only  device  defined  at 
initialization  time.  Other  devices  are  defined  using  the 
"Def ine_device"  configuration  function  described  below. 

Whether  or  not  Multics  needs  separate  operator's  and  SSO  termi- 
nals is  still  an  open  question. 

The  initialization  of  process  control  defines  the  initial 
process,  the  initializer  process.  There  are  no  other  processes 
defined  initially. 

Initialization  of  the  common  V-functions  is  completed  by  setting 
"audit_log"  to  undefined. 

The  initialization  of  storage  control  starts  by  setting  the 
information  about  the  mounted  volumes  ("Drive")  to  "undefined".  The 
remainder  of  storage  control  initialization  depends  on  whether  or  not 
this  is  a cold  start,  as  indicated  by  the  argument  "cold_start".  If 
this  is  not  a cold  start,  then  the  segment  hierarchy  and  the  Logical 
Volume  Record  File  (LVRF)  are  assumed  to  be  unchanged  since  the  last 
shutdown,  i.e.,  the  storage  system  is  intact  on  disk. 

If  this  is  a cold  start,  however,  no  hierarchy  exists  on  disk, 
and  a new  one  must  be  created  by  the  kernel  and  the  (unspecified) 
restore  subsystem  (which  is  trusted).  For  a cold  start,  the  root  is 
created  with  only  one  entry,  which  is  a description  of  the  root 
itself.  No  other  segments  or  directories  exist.  They  are  created  by 
the  restore  subsystem  from  a previously  created  backup.  Also,  the 
LVRF  is  set  to  undefined.  Entries  in  the  LVRF  are  defined  by  the 
"Def ine_LVRF"  configuration  function.  Note  that  entries  in  the  LVRF 
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cannot  be  removed.  The  LVRF  can  shrink  in  size  only  as  the  result  of 
a cold  start. 

Initialization  Configuration  0-functions 

Figure  14  illustrates  configuration  0-functions  that  are  used  for 
initialization.  It  is  expected  that  most  of  these  functions  will  not 
be  called  directly  as  the  result  of  an  operator  command,  but  will  be 
called  by  the  verified  software  processing  the  CONFIG  deck.  For 
example,  one  of  the  initialization  configuration  functions  already 
mentioned  is  ”Def ine_systera_controller”.  This  function  is  called  by 
verified  software  that  is  processing  the  CONFIG  deck,  to  specify  which 
system  controllers  exists,  even  though  they  may  not  yet  be  configured. 
The  exceptions  for  all  of  these  functions  check  that  they  are  being 
called  by  the  SSO  terminal  with  a ”system_high”  access  level. 

The  0-function  "Def ine_device”  provides  a way  to  define  what 
devices  are  available.  An  exception  for  this  function  checks  that  the 
; maximum  access  level  being  assigned  the  device  dominates  the  minimum 

for  the  device.  The  effect  of  this  function  is  to  set  the  minimum  and 
maximum  access  levels  for  the  device.  The  current  "access__level**, 

• "owner”,  "status",  and  "buffer"  of  the  device  are  set  to  "undefined". 

"Def ine_LVRF"  is  used  to  specify  an  entry  in  the  Logical  Volume 
Record  File  (LVRF),  which  defines  the  logical  volumes  in  the  system. 
The  effect  of  the  function  is  to  mark  that  the  specified  LVRF  entry 
exists,  but  that  the  volume  is  not  mounted.  Also,  the  access  level, 
number  of  packs,  and  quota  of  the  logical  volume  are  set. 

The  0-function  "Def ine_system_controller"  is  used  to  make  the 
existence  of  a system  controller  known  to  the  system.  System  control- 
lers not  made  known  at  initialization  time  cannot  be  configured  later. 
The  effect  is  to  mark  that  the  controller  exists,  but  is  not  config- 
ured. The  controller  can  eventually  be  configured  using  the  hardware 
reconfiguration  functions. 


INITIALIZATION  REVIEW 

We  have  described,  in  this  section,  how  Multics  is  currently 
initialized,  and  how  the  initialization  process  must  be  reorganized  to 
accommodate  a kernel  based  Multics  system.  The  security  kernel  must 
be  securely  initialized,  but  the  rest  of  initialization  can  be 
performed  by  unverified  code.  The  V-f unctions  that  comprise  the  top- 
level  specification  are  initialized  by  the  0-function 
Initialize_top_level.  Once  the  kernel  is  initialized,  it  is  installa- 
tion independent  and  must  be  reconfigured  to  the  hardware  using  the 
initialization  configuration  functions. 
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/*  Initialization  Configuration  0-functions  */ 


0_f unction  Def ine_jlevice  (device_id,  device_max_al,  device_jnin_al, 
<terrainal>) 

exception 

terminal  SSO; 

Device(SSO)  .access_level  ^ ’’system^high”; 

T)ominates  (device_jnax__al , device_jnin_al ) ; 

effect 

Device  ( device_id ) .nax_al  = device_jnax_jal; 

Device  (device__id)  .min^al  = device_min_al ; 

Device  (device__id)  .access_level  = device_min_al; 

Device (device_id )• owner  = "undefined”; 

Device (device^id) • status  = "undefined"; 

Device (device_id) .buff er  = "undefined"; 


O_function  Define_LVRF  (vol__id,  vol_access_level, 
voljuota,  <terminal>) ; 

exception 

terminal  ^ SSO; 

Device(SSO)  .access_level  ^ "system_Jiigh"; 

LV_def  ined(vol_id) ; 

effect 

LVRF(vol_id) .mounted  = "false"; 

LVRF(vol_id)  .access_level  * vol__access_level; 
LVRF(vol_id)  .quota  = vol__quota; 


0_f unction  Def ine_syst em_cont roller (controller , <terminal>) 

exception 

terminal  ^ SSO; 

Device  (SSO)  .access_level  ^ "system_Jiigh"; 
effect 

Controller__data(controller)  .exists  = "true"; 
Controller_data (controller) .configured  = "false"; 


Figure  14.  Initialization  Configuration  0-functions 
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APPENDIX  I 


Functions 

Add_cpu  34 
Add_jnemory  31 
Add_pd_re cords  33 
Branch_path  10 
Configuration  29 
Controller_data  29 
Define^LVRF  46 
Define^device  46 
Deflne_system_cont roller 
Delete_cpu  34 
Delete^memory  31 

^ Delete_pd_records  33 

Dir_branch_path  10 
EIMA_swltch_jiumber  27 
IOM_jnemory_port  29 
I0M_port  40 

Initialize_jtop_level  42 
Make_full_path_naine  12 
Mount^request  13 
Nmemories  29 
Nprocessors  29 
Parent_j)ath  12 
Path_accessible  12 
Path_to  uid  12 
Pd_size  29 
Processor_data  29 
Read_mount_request  15 
Reinove_upgraded_jquota  17 
SS0!_access_level  13 
Set_Drive  17 
Set_device_al  16 
Set_mount_list  17 
Set_j5egment_al  16 

4 Basic  Definitions 

bootload_cpu  40 
bootload_cpu_jnemory_port 
bootload^jnemory  40 


INDEX  TO  SPECIFICATIONS 

cold_start  40 
control^mem  27 
control_proc  27 
controller  27 
controller__data_type  27 
count  27 
cpu__id  2 7 

device__access_level  40 
device_inax_al  40 
devlce_min_al  40 

46  full_path  10 

full_path_length  10 
full_j>ath_jiame  10 
full_j)ath_jiaine_length  10 
full_j)ath_naine_type  10 
Icpu  27 
idevlce_id  40 
lentry  40 
imeiti  2 7 

iprocess_id  40 
iuid  40 

max_controller_port  27 
raax_processor_index  27 
max_processor_port  27 
mem_port  27 
meinory_port_number  27 
inount_request_type  10 
paging_devlce_size  40 
path_naine  10 
path_naTne_length  10 
path_naine_jtype  10 
processor_datajtype  27 
processor_index  27 
processor_port_jiuTnber  27 
record  27 
terminal  10 
vol_#_pf_j)acks  40 
vol_access_level  40 
vol_ld  40 

40  vol_quota  40 
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